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ABSTRACT 


This paper presents a case for basing Level 3 (the network layer) af Amateur Packet Radio an the “datagram” 


further pr that the DARPA protocols IP (Intemet 


. it 
Protocol) and TCP (Transmission Contral Protocol) be adopted 


intact as the standard Level 3 (Network) and Level 4 (Transport) protocols for Amateur Packer Radio. 


I will then provide an overview of TCP/IP, explain why it, as a datagram protocol 


, iS more suitable for our needs than the 


virtual-circuit protocol CCITT X75, and show how it would be used above the AX.25 Level 2 protocol already in use. 


1. Datagrams and Virteal Circuits 


A fundamental characteristic af ARPA (and several 
others, e.g., Xerox PUP [15]) protocals is the choice of 
the "daragram” as the ntal unit of communication 
caren of da diag aizoah gah is cid oval 
com: gram with its rival, 
the Wirtual Graut,” is needed. 

1.1 What is a Datagram? 

The word "datagram" is coined from the words “data” and 
“tdegram.” Like telegrams, datagrams are simple one-shot 
messages; each is self-contained in that it includes the full 
source and destination addresses, control information and 


user data. Each datagram is i tly processed 

the network. garg ctype bya pct sith 
to route network is ly 
contained ein exh ds No state need be 


maintained by a packet switch between datagrams. There 

are many analogies to tis mode of operation besides 

telegrams: mailing a letter, sending electronic mail, or 

oe ee radio National Traffic 
em. 


The network makes a “best effort" attempt to deliver each 
datagram. If datagram delivery is impossible (e.g., due to 
network congestion, buffer overflow ar an m or 
unreachalde destination sage a packet ee 
discard a dat Same datagram protocols (such as 
IP, to be descnved later) ire that an effort be made to 
notify the sender af the probiem. 
Dat are never discarded lightly; however, there are 
ically vatine Goose oh “eat ear’ that can be 
before “givin ees a datagram. Frequently, 


in some other way, ¢€g., by easing throughput or 


In any event, a datagram user must always be prepared to 
cope with the occasional loss, out-of-sequence delivery or 
duplication of datagrams caused by network congestion or 
switch ee link failure. Since oer aed Ge 
service, a ate, 
ex to-end acmowledgements’ and retransmission of lost 
datagrams is generally used “on top" of the unguaranteed 
datagram service. 
1.2 And In The Cther Corner... The Virtual Circuit 
As the name implies, “virtual circuit" networks (hereafter 
abbreviated "VC networks") are oriented to provide the 
ee 8 ee ae ace, 
network sets up a fixed path though the network to 
the destination for the duration of the user's connecdan. 
Because the may be shared by several users (i.e., the 
physical facilities are not dedicated to a single user), the 
connection is “virtual.” 
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A special “call " packet propa through the 
network, and cach maith: ad a "artuad call“ to an 


a 
established at setup time, all packets follow the same route 
to the destination. As long as all links and switches 
traversed by the virtual call remain functional, the users’ 
data will be properly delivered in sequence. However, 
should a switch crash or a link fal, all virmal crauits 
using the affected switch ar link will be dropped and any 
data in transit will be lost. 

When the user is done with a virtual crauit, it is deared. 
This removes the information about the cali from the 
memory of each packet switch alang the call’s path. 


1.3 Discession: Dategrams Vs. Virtasi Circuits 


Many applications, such as remote terminal access to a 
computer, require a reliable, flow-contolled “stream 
connection" between two end points, regardless of how 
this might be implemented in the bowels of the network. 
Therefore, the issue is NOT whether the user should be 
provided with a reliable end-to-end stream, but rather how 
it Ought to be implemented. Should the concept af a 
"virtual circuit’ be confirsed to the endpanrs of a 
“connection” or should it permeate the design of the lower 
levels of the network? 

The choice has many implications for reliability, 
flexibility, ease of implementation, efficiency, and 
adaptability to varying user-level service requirements. 
The decision is a tradeoff, and aften the choice depends 
cn those characteristics omsidered most impctars. 
Neither approach is always superior. 

1.3.1 Ease of Implexentation Datagram packet switches 
are considerably easier to implement than VC switches. 
The lack of special “call setup" and “call daring” packets 
means that ail packets are alike as far as the switch is 
concemed. All that it has to do is select an ing link 
for the packet (typically based on a routing table is 


periodically updated fram its neighbors) and send the 
packet on its way. If there is a serious problem with the 
packer, the switch is entitled to it; no intricate 


error-recovery procedures are needed. Since the “what to 
Co when things go " section is the largest, most 
copes Reled deg epiae ed regraniindnr pend 
programming project, this results in an enormously easier 
fodog job. 


1.32 Dynamic Routing As already mentioned, virtual 
Circuit networks establish fixed paths thr a network of 
packet switches and links. If a given link fails or beccenes 
overly congested, there is no easy way to reroute 
established virtual circuits via altemate paths. 


Detagrams, with their self-contained nature, mey be 
individually routed without to any end-to-end 
connections that might exist at a higher protocol level. 
This makes it possible to react on a per-packet basis to 
Changing traffic conditions and network reconfigurations. 
Much of the work to date in non-amateur packet radio has 
been dane in a mobile environment, and dynamic routing 
is essential here because of the constandy changing 
topology of the network. 
While it is certainly possible to make routing decisions 
based on link loading at crcuit setup time in a virtual 
circuit network, this is less responsive to rapidly changing 
network conditions than the ability to route on a per- 
packet basis. 
1.3.3 Overhead This is the primary objection that is made 
against datagram protocols. Vit Gircuit protocols 
require that complete addresses be sent only at aircuit 
setup time. Once the table entries are made in each 
switch along the path of a virtual crouit, only the index 
into this table (referred to as a “virtual arcut number") 
nesd be part of each data packet far the switch to route it 
ly. Depending on the size of the data fidds, the 
ger headers involved in datagram packets can involve 
considerable overhead. This is primanly tue with 
interactive terminal traffic that often consists of single 
character packets; it is much less of a factor when data 
fields are larger. 


On the face of it, virtual cirouit protocols seem to win the 
overhead argument hands down. However, there are 
applications where the direct availability af a datagram 
service to the user (eg., the ARPA User Datagram 
Protocol, UDP [11]) results in fewer packets and bis 
being exchanged to accomplish the same task. 


Such applications typically have a “client-server” 
characteristic. For example, a database server might be 
set up to provide "directory information” (i.e., providing 
the network number corresponding to a given station’s 
name). Most transactions with such a database server are 
short; the request and replies each fit easily into single 


traffic than if one-shot data 
network level, avoiding the overhead of setting up a 
virtual circuit for such a short “connection.” 


To answer this objection, the X.25/X.75 protocals include 
an orional “fast select" feature that allows user data to be 
sent in the same packet with a call request. Fast select is 
not, however, a substitute for datagrams. A virtual arcuit 
is still being established, although for a short ume. A 
reply packet (typically a INDICATE), with or 
without data, is sull from the destination within 
pesrspe ioe! bageal Mapes y and the data fields 
contained in either packet are limited to 128 bytes; there is 
no fragmentation facility. This is considerably less general 
than a “irue” datagram facility. 
However, in the common situatian where the application 
requires an end-to-end conmecion for a relatively long 
time, virtual circuit networks do require fewer tits to be 
transmitted than do datagram-based networks. 
situations where the traffic consists primarily of single- 
character packets (e.g., interactive terminal access) and 
saps use af slow and ive transmission saci 
is af supreme importance, ower per-packet over 
af the virtual arcuit approach can be the overriding 
factor. [13] 
While amateur packet radio is curently severely 
constrained by obsolete Bell 202 modems and 1200 baud 
iret ee a ee senna a soi 
r speeds ers magmit are now being 
peakeel [16] Since these modems will not cost much 
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more than those autenily used (assuming a dedicated 
racic), this will almost campletely mitigate the overhead 
argument. 
1.34 Reliability Because a datagram contains all 
information necessary to forward it anto its destination, 
no state has to be maintained in a datagram packet switch 
between pack=ts. This makes datagram networks much 
more resistare to real-world occurrences such as power 
itches, software failures and nosy visitars who push reset 
toms. 


Since the reliability requirements are less for a dat 
switch (since it has no volatile table of virtual arcuts to 
safeguard) such measures as battery backup can often be 
i eae witt.! The only information that 1s ppically lost 
within Catagram packet switches during failures are 
oot aay tables (assuming a distributed routing 
algorithm is used), but these can be quickly rebuilt from 
cne’s neighbors. Virtual crcuit switches, on the other 
hand, must maintain the information provided to it at 
Circuit setup time to route successfully each cata packet af 
a virtual connection. In , this information cannot 
be rebuilt from cne’s neighbors, and the end user must 
oon circuit and recover from any lost 
a. 
To achieve maximum reliability against intemal network 
problems, both ditagram virtual circuit networks 
require a higher-level end-to-end “transport” protocal. A 
trans recovers from various errors that might 
cccur in the network (lost, reordered or duplicated packets 
in a datagram network, or dropped virtual arcwts in a 
virtual circuit network). The transport protocol used atop 
the ARPA datagram protocd, IP, when reliable stream 
communication is desired is called TCP (Transmission 
Control Protocol). 
A major advantage of an end-to-end protocal such as TCP 
is that it provides Pomme against data corrupic (as 
well as loss) along the ENTIRE network path. Link level 
error detecting codes (such as the 16-bit CRC in AX.25) 
protect only against errors on transmission links. Without 
isdn whan a user is still vulnerable to data 
corruption can occur in a packet switch between the 
reception af ra rae and its retransmission with a freshly 
regenerated CRC. The probability of this occuring in a 
single packet switch may be acceptably small, but in a 
large network composed pximanly of inexpensive 
micrccomputers without memory error detectian, errors 
are inevitable. 
Many virtual-crcuit daim that their networks 
provide “reliable” VC service with less complexity than 
datagram networks because they do not “need” an 
elaborate end-to-end ge pln wears However, many 
X75 networks provide Ni to-end transport protocal 
at all, and as a result the user is still vuinerable to failures 
within the network that can lose infommation or drop 
comnectians. In practice, this happens often enough to be 
annoying. With an end-to-end transport protocol on a VC 
network, the reliablity can parent that of, say, a 


TCP/IP network, but now implementation 
comiiexiy is grester because of the reaundancy a 
multiple levels. 


1.3.5 Grades of Service VC networks are implictly based 
on the assumption that all applications requre a reliable, 
flow controlled stream “connection.” However, there are 
several real-time* applications that either do not require 


. Most ilures brief, and if the switc 

a MO ES aiitaite giver cieua: Gaava dt te ent 
Bal eles (ya tuna "bee co a 
transfey, not a connection. , 

2. "Real time” as that the information 
ht eee ee a uni Ctr a suv uoe unl 


this cf service or cannot tolerate any overhead 
intr by it. 
The best e of an application in this category is 
packet vaice. le conversing on a telephone channel 
are sensitive to long transmission delays, especially if they 
are irregular. In contrast to data transmission, however, 
human s can tolerate a certain amount of lost or 
data because of its great redundancy, and 
“perfect” reliability may be sacrificed to reduce delay. 
Other es of real-time applications might include 
television (“digital SSTV") and satellite telemetry. In each 
case, there is lite point in retransmitting lost “old” data 
because "new" information will arrive shortly to take its 
a For example, real time satellite telemetry gai 
ittle from retransmission af lost frames; the user might as 
well wait for updated information (and then interpolate 
the missing values) instead af falling behind by trying to 
recover data that is already out of date. If a somewhat 
higher degree of reliability is needed (but the cost af 
“perfect” reception is too high) the satellite might simply 
repeat each frame of data several times to increase the 
chances of successful reception, ar use other more 
complex forms of forward error correction (FEC). 
In a datagram network, these kinds of gpplication-speafic 
tradecffs are easy. For example, contra hits in each 
datagram might select the use of hop-ly- 
In a VC retwork, hovever, 


scarily De ear traffic) but because VC networ: 
typicaily traffic on established virtual circuits cn a 
first-come, first-served basis this is difficult to do. 


While it may be a while before amateur packet radio 
networks have the capacity to handle packet vace at a 
practical level, it would be unwise and shortsighted to 
Sar api nd gal gh fe lg 
our networ » Jani 
of resources that could occur fa common ceteris cou 
satisfy the needs of amateur data and vaice users. 


1.3.6 Broadcasting Virtual circuits are inherently point- 
to-point and usually full-duplex, and thus they do not lend 
themselves easily to the notion of a “broadcast” message. 
Sending the same information to N receivers requires 

N virtual circuits be created, one to each receiver, and 
that N copies of the data be transmitted. This is dearly 
wasteful when the underlying media permits broadcasting 
(such as Ethemet [10] or radio), and datagrams are a 
much more nafural sdluton. 

Given that reliable delivery to every receiver in a 
broadcast environment is much mare nsive than 
reliable delivery to a single destination, it is even: more 
appropriate to provide an unguaranteed service. As with 
simple point-to-paint connections, a reli ability-improvi 
mechanism appropriate far the specific application woul 
then be implemented on top af basic ast datagrams. 
Other situations where broadcast mechanisms are useful 
indude the constructim and exchange of routing 
information, and in distributed processing to manage a 
collection of systems providing a set of services. 

As with dynamic routing, datagrams do no, in 
themselves, salve every problem involved in broadcasting, 
Bi ty ek praca Keg 
networks. 


Seating, gees, Pim tashed cavecdy. 
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2. What & TCPAPT 


The ARPA Transmissian Control Protocol oD [) and 
the ARPA Inemet Protocol (IP) [1] are part af a larger 
collection of protocols that enjoy widespread and rapidly 
growing usage within numerous commerdal, research and 
military computer networks. 

Before delving into the internals of these two protocols, it 
is necessary to understand the needs of thar developers 
and environment where they were designed. 

The ARPA research community thar designed TCP/TP is a 
user (as opposed to a vendor) of hardware and 
communications facilities, this a major impact mm 
its design. [9] A basic requirement was the interconnection 
Solara eesti Sig pad pes ae using the widest 
possible variety of link-level networking hardware and 
protocds. This was ant for two reasons: first, 
much of the hardware already existed and couldn't be 
thrown awzy. Second, the user community wanted a 


becoming ' in” to any ane vendor's products This 
is in contrast to a vend 
standards that favor the use af anes’ own products over 
those of the carpettian 

It was found that the networks in use vary radically in 
their characteristics. Some suppart the orn of 
“connections”; others only ide unguaranteed delivery. 
All vary widely in reliablity, transmission s and 
addressing formats. The datagram was the anly feasible 
choice as the “common unit” af transmissicn that could be 
“encapsulated” on each of these heverogeneous networks. 


Cther ARPA requirements included robustness in the face 
of intemal network failures and reconfigurations, 
provisions for precedence, class-of-service security 
classification, and optional user specified routing. Because 
no. existin Is satisfied these requirements 
(including X.25/K.75), it was necessary to design 
a new set of protocais. 
The widespread acce of TCP/IP outside the military 
community that originally s its design shows its 
success in meeting the of a wide variety of users, 
not just those of the military. The latest available figures 
show that address assignments have been made to a total 
af over 3,000 distinct networks of ing sizes. About 
half of this total represent Defense Govemnment- 
sponsored research izations that are interconnected 
to form the ARPA Intemet, while the rest are 
independent private (mostly commercial) networks. While 
the exact total mumber af hosts that s the Internet 
protocals is unknown, the ARPA et host file 
currently contains 1,146 hosts, ranging from IEM PGs to 
large timesharing systems. 

Planning activites within the Intemational Standards 
Crganizaticn (ISO) now indude the desi of a 

based on TCP/IP (TP4), although the T seems to 
remain adamantly opposed to this type of protocol. 

In the following sections, I will discuss the major features 
cf the ARPA IP and TCP protocds. In genera, the 
statements made earlier about datagram protocols apply to 
TCP/P. In addition I will vate out some differences 
between TCP/IP and X.25/X.75 that are specific to those 
protocos and not necessarily related to the 
datagram/virtual craut selection. 

2.1 The Internet Pretecel (IP) 


The Intemet Protocol (IP) occupies level 3, the network 
layer, in the ARPA protocol “suite.” As its name implies, 
IP is the “universal language” of the network, it is the 
“Esperanto” of a larger network bult up through the 
interconnection of many smaller, heterogeneous networks. 


TP is a dat protocol that makes minimal assumptions 
or de feet Ge IP headers contain only that 
information necessary to provide network functions such 
aS addressing, classes service, precedence, etc. In 
particular, there are no end-to-end features such as 
guaranteed delivery, flow cantral, sequenang, or other 
services commonly found in virtual areuit prcvscols. Asa 
result, IP is cat e and easy to implement on a wide 
a oe , indudi fac Soc gaperpeceeete 
support vir circuits. ate y points 
(hereafter called "gateways”) only need implement IP in 
addition to whatever link level protocals are being used; 
any end-to-end functions remain the domain of higher 
level protocols in the user systems. 

The maximum size of an IP datagram is 65,536 : 
Since many (most?) networks cannot handle alee 
packets, IP provides a feature called fragmemation. This 
allows a gateway faced with a datagram that won't "fit" 
into a given link level protocal to split it into several 
smaller datagrams that will. Each “fragment” behaves 
like a separate datagram in its own nght and will 
propagate independently through the netwark. Only when 
they arrive at their destination will they be "reassembled" 
into the original, larger datagram and passed to the next 
layer protocal. As we will see later, tis is an important 
7 ce a eel 


Each IP datagram contains a "Time To Live" (TIL) field 
that is decremented as the datagram propagates through 
the network. If the TTL reaches zero before the datagram 
is delivered, it is destroyed. Of course, the TTL field is 
set to a large enough value so that the datagram is likely 
to reach its destination; however, if a transient routing 
loop occurs in the network the datagram will not circulate 
indefimtely. Even if the routing loop eventually 
disappears, the TTL field protects higher level protocals 
by establishing the maximum interval when they must 
against duplicates of a particular datagram, The 
feature provides backup protection against buffer 
scent Aerob cae age: dren empeicapea oan 
network indefimtely. A cal (although aay ctell 
impractical) analogy might be the plaang of a time bc 
in each car entering New York Gty. Normully, the cars 
leave the city in plenty af time, and there are few (cr no) 
explosions. If gridlock occurs, however, even in the 
absence of any other actions taken the problem is 
guaranteed to go away eventually by itself! 


Several features of IP are not used frequently enough to 
justify their incdusion in every datagram ‘These "IP 
cee are listed in [2], but the most interesting ones 


1. Source routing. Normally, gateways do their own 
routing, but two forms af user ("source") specified 
routing are available. One, "strict source routing” 
specifies the exact path that must be used by 

gram; if this path is invalid, the datagram is 
discarded and a failure report is sent to the user. 
The other form, “loose source rounng" allows the 
user to anly partially specify the route; the gateways 
are free to determine paths between each user- 
specified point. 

2. The "recard route” option asks the gateways to route 
fe Gran anomaly Hae cre 3 te 
datagram the path used. 

3. Related to the "record route” option is the “Internet 
Timestamp" option. This option requests that each 
gateway record the time when it processed the 
datagram. 

Most datagrams are sent without of these options. 
However, they are extremely useful for special functions 
such as testing or collecting statistics about specific paths 
within the network. It should also be pointed out that 
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X.25/X%.78 provides none af these features. If they are 
considered necessary for amateur packet radio they would 
have to be added to those protocols. 


A specdal “protocol” called ICMP (Internct Contrd 
Message Protocol) is considered an integral part of IP. 
pe 
@ report back to the onginator of a datagram when same 
unrecoverable error ccaus. Gateways are required to 
generate IOMP messages whenever a datagram must be 
dronped for any reason, with the sale exception that ICMP 
messages are never generated about other ICMP messages 
(to avoid endless loops). ICMP messages report such 
error Situations as invalid IP header formats, unreachable 
destinations, buffer congeston, tmeto-live fields 
expiring, etc. 
Other ICMP messages are of a more advisory nature. 
The “Redirect” ICMP message is used to notify a host's 
routing algorithm that an altemate gateway is a more 
imal path to a given destination. There is also an 
ICMP “echo/echo reply” message pair that allows a host to 
monitor network performance by “pinging” echo requests 
off selected destinations, perhaps using specified routes. 


2.3 The Transmission Central Pretece! (TCP) 


TC? is the standard ARPA Level 4 (Transport) protocd. 
TCP, and noe PP, provides optional sad end “virtual 
circuit" service to applications that ire it. Consistent 
with the concept of A deca cewek: TCP resides only 
= ee ee 
computers containing t ication programs) and mx in 
the intermedi ate i etc a the (potentially) 
unreliable service provided by IP and provides a reliable 
Stream. Therefore it must uence datacrams that have 
feen delivered ou i secumice by the ner: detect and 
discard duplicate datagrams generated by the network, 
and request retransmissions when data is lost altogether. 
While internal details of TCP are beyond the scope af this 
paper (see [3] for the formal specification af TCP), several 
of its key features can be mentioned here. 


One is that each character of data has its own sequence 
number. This doesn’t mean that TCP sends single 


character packets; TCP “ " (de, the datagrams 
that it sends by way of IP) can be of any length up to a 
limit negotiated by the "maximum ent size” 


cea abl ele omitrast fo X25, receiver 
a edgments exactly how many bytes of buffer 
space (the “window") are availabe. 
In X.25 level 3, ence numbers refer to “packets” that 
could be af any size fram 1 , say, 256 bytes. The 
receiver’s “vocabulary” for flow control is limited to two 
ases: “receiver ready (RR)" and “receiver nox ready 
RNR)." How MUCH the receiver is actually ready to 
accept when it says "RR" must be agreed on in advance 
and specified to the protocds. The maximum is 7 with 
standard sequence numbering, while a typical value is 2 
packets. This means that the receiver cannot confidently 
indicate that it is ready to receive any data at all unless it 
has at least enough buffer space for two full-size (256 
byte) packets. Ar the other end of the crouit, the sender 
may send no more than two (in our typical example) 
packets, even if each of these packets contains only a 
me character. This obviously limuts efficient buffer 
ization, and can severely limit throughput as well. 


2.3 AX.25 and Digipcaters: A Peor Man's TCP/IP? 


Those who have followed the development af AX25 
Level 2, particularly the digipeater feature, may have 
ee ee a ee eee 
done under TCP/IP. 

What we call "“AX.25 Level 2” is, in fact, composed of 
two distinct “sub-layers.” The of these two sub- 
protocols is the familiar connecuon-oriented, end-to-end 


byte stream protocol essentially identical to X25 LAPB. 
However, the essential changes that ee ee ee 
LAPB to form what is now known as AX.25 Level 2 


oes i 
addition, ‘should digipeaters be used, each packet contains 
a "strict source route,” in IP terminology. 


ee oe ee) 
ia ie are gs it looks reasonably ordi 
level l. However, when digipeaters are 
circuit level of AX.25 (the transmission of 
es ne ee oe etc) is pein cepa 
serve as an endto-end sunspot 
TCP. The digipeater is, in fact, noting more'thm 2 
datagram bas cket switch, although it is very simple 
because it can’t Go routing. 


Nor would automatic routing by digipeaters be desiratle, 
ed coe ca eS ee 
not a very transport proto: 
For ecarle, it is totally ccreced by pucker that arrive 
out af order or duplicated, events that inevitably occur 
occasionally in datagram networks with automatic os 
mechanisms, but not on the point-to-point links for whi 
it was designed. There are also situations sce 
higher lev ponds ts 5 umacoepiae 
higher s is unaccept havior ¢ " 
transport protocdl, the user’s last defense against 
corruption. 
However, AX.25 without digipeaters is eurey suitable as 
a link level mechanism for relaying IP datagrams from 
ane packet switch to another, and it can play an i 
synergetic role here. A major problem with our existing 
ae hoe digipeater networks is the lack af hop-by-hop 
acknowl If a packet in transit down a chain af 
digipeaters is lost for any reason, the transmission must be 
restarted back at the source. Even more wasteful is the 
loss of an io cf the dacs ba 


problem. However, many pf 

‘hidden terminal problem," pee RF links and 
overloading, cause significant numbers of ae to i 
lost in ‘digip er networks. If IP da 

be sent in “ra frames, a long tihop TCP/IP 
connection would suffer as much from this problem as a 
lang somuuly dedcisiog connection. However, if an AX.25 
link existed een each point of a long path, with the 
regular acknowledgment mechanism being used to increase 
the chances af a packet being successfully relayed onward, 
the efficiency and throughput of our network would 
increase dramatically. The end-to-end transport functions 
eed ins ene a much more robust 


Renae risa eos. by ty 1 would be an ees wet 


occur anly when a link failed or became congested within 
the network. 


It is in this way that AX.25S, as a layer 2 protocol, and 


consummating such a marriage. Much of it is modeled on 


s The ce senna pollen in peck 
Pear (and defer to) the wars emaission Being wire 
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an existing standard for the transmission of IP data 
over Public Data Networks using the X.25 interface. 


3S. Sending IP Datagrams on AX.25 Links 


cn to be easily “enveloped” in a wide variety 
Frotocols, and the AX.25 link level is easily 
Sarak cf sareig it. However, a standard must be 
established, ae several items ria addressed. A 
proposed stan is ented ; &@ summary is 
oman AeA 
3.1 Pretecel ID 
The Layer 3 Protocol ID byte immediately follows the 
contra field in AX25 Level 2. Until version 2.0 af 
AX.25, ae a ge ae a 
aera | no layer 5", i.e., send the packet directly to the 
For AX.25 Version 2.0, the Protocol ID byte 
hex CC has been defined to mean “Intemet Protocdl.” 


3.2 Service Mappings 


Two of frames (I and in AX.25 
informetion. Hane ee pg the full’ LAPB 


access to the 
do not provide gu eed delivery. How should the 
“class af service” bits in the IP header control the selection 


of the frame type used to send the datagram? 


Two “class-of-service” bits are relevant, “low delay” and 
ee the low day Gi would seem to be the 


I o9 Ul frames. This choice ma saat Mle asriecgc ein 
SoeHONS EBs » experience in the reliability of a given RF 


It is not dear how the “throughput” bt should be 
interpreted, so far the time it should be ignored. In 
the ARPA ae it is gateways that must 


choose betw a low delay low Bae oy 
terrestrial cand nd a high throughput (but large 
satellite channel in reaching a given destination. 


3.3 Fragmentation 


The AX.25 Level 2 document specifies that the maximum 
size of an I-fiedld shall be 256 octets. This means that an 
seed ug (Ps Ep than 256 octets must be split 
into several gmentation facility. Since hosts 
on the ARPANET Soo ee oe ae Cees (© 
reduce header overhead) duis facility must be i 

if our network is to interconnect with narAX. aa 
sites. 


3.4 Address Pescilntion 


An IP address is a fixed-size 32 tit field, too smill to 
contain an amateur callsign. Widening this field is out af 
the jon since it would no longer be IP (remember 
that IP is the basic, universal protocol that is absolutely 
standard across a wide variety of systems). Nor would it 
U dey ca fe, bu dis i a tuple telepsed W uy 
if t, is a c rele to my 
companion paper, “Addressing wa Rou oa es In 
Amateur Packet Radio.” 

Therefore, there must be same way to map between the 
addresses used at the IP level and the addresses (call 
oo) oe ee evel, Fortunately, an 
almost identical problem has already been solved in the 
ARP Scoumanly, Ot 8 teeing Dearne oer ae 
Ethemet local area network. 


Ethernet link level addresses are 6 bytes lang. Unique 
addresses are pr by the manufacturer into a 
ROM aon each met controller, and they cannot be 
easily ed by the user. After several unsatisf 
ad-hoc Kludges, a salution ed by David Plummer af 
MIT was widely adopted, and it has worked well. 
Plummer’s Address Resolution Protocol, or “ARP” [6] 
(not to be confused with "ARPA") has been widely 
adopted and is enough to work on cher 
broadcast-type local area networks besides Ethernet (such 
28 packet radio). 


ARP works as fodlows. Whenever a station needs to 
determine the link layer address (2.g., the Ethernet 6-byte 
address or the AX.25 Level 2 call sign and substation ID) 
otn pet: to a given 32 lit IP address, it broadcasts a 
special "ARP Request” packet on the channel. The station 
with the requested address responds with an "ARP Reply” 
oe containing the desired link level address. 

aturally, to avoid having to invoke ARP for every 
datagram each IP station maintains a cache table af IP to 
link address correspondences. This table does not have to 
be large since it will contain only those stations that are 
“neighbors,” i.e., stations to which packets can be directly 
sent using level 2. Packets addressed to more distant sites 
will be sent first to a gateway, and it is only the gateway 


whose link layer address is needed. Entries in the ARP 
table are , occasionally purged, and replaced with the 
reply toa ARP request to allow for the possibility of 


network reconfiguration (i.e., stations changing their IP 
addresses 


The beauty of ARP is that it works automacaii) and 
trans ly. The IP layer need not be conce with 
i ‘yer addresses, and there is no need to maintain 
manually a table af IP and link level addresses. In 
practice, it 1s even possible to swap Ethemet boards (and 
their addresses) between computers without any adverse 
consequences. 

ARPA has already assi an ARP “hardware type" 
oe Teel 3 ARP Le 


value of 3 to est and rep! 
ee Identifier 
3.5 Addressing and Reuting 


This a major challenge facin higher level Amateur 
Packet io protoods, vimud erat eee Since 

this paper is to argue the case for TCP/IP, 
iat ily Cook oat at Wig SR ree ep 
Routing Issues in Amateur Packet Radio,” to this topic as 
these issues apply equally to an IP or a X75 network I 
will simply mention here that ARPA "Class A" network 


Se ee en eae 
radio through the foresight of Hank Magnusk, 
IP addresses are always 32 hits wide; addresses within the 
ARPA assignment would contain 44 (deamal) in the first 
8 bits of the address, and the assignment of the remaining 
24 bits is left up to us. This provides the ability to 
address 16,777,216 individual stations. 


4. Conctusions 


It is difficult to sumrmarize in just a few words what has 
been argued about at length by so many people, only a 
Se aie, Gee, HER 

io. Nevertheless, TCP/IP’s proven flexibility and 
adaptability makes it an extremely attractive candidate for 
our needs. It already provides virtually every function we 
need in an amateur packet Saieag Se at 
exactly as-is, keeping open sitility rect 
caeieenecion with non- amateur TCPIP networks. 
TCP/IP is ideal for amateur radio, a heterogeneous 
environment where stations came and go, propagation 
paths change, satellites rise and set, and users experiment 
with new applications and transmission schemes 
unforeseen at present. 


In contrast, %.25 and X.75 are much more limited 
protocols designed for a meous common cafrier 
eivironment with static network topddogies, reliable 
nodes, point-to-paint transmission lines, and a limited set 
of user services. Many ad-hoc changes would be required 
if they were to be used on amateur packet radio, creating 
new, umigue and incompatible protocols. Interconnection 
with non-amateur networks would require protocd 
conversion gateways, a totally unnecessary complication. 
Virtually all non-amateur packet radio systems use TCP/IP 
(and mone whatsoever use X.75, to my knowledge). 
Furthermore, the fact thet amateurs are already using a 
protocal much like TCP/IP (i.e, AX.25 with digipeaters) 
gives strong support to the convenience, flexibility and 
simplicity af this approach. If we adopt TCP/IP, we will 
be able to tap the enormous amount of experience that has 
been gained (and made public) with it over its 10+ year 
evolution. If instead we adape X.75 and the higher layers 
of X.25, we will be forced to salve (or endure) many af 
its deficiencies in 2n ad-hoc, unique and time consuming 
way. 
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6. Appendix A 


2. The maximun length of an IP datagram, including 

the IP header, headers far higher level protocol(s), 
and user data, shall not exceed 256 bytes. The IP 
fragmentation/reassembly facility shall be used on 
any datagram larger than this limit. Te ety 
of increasing the 256 byte fragment size limit is a 
subject for future study. 
Gateways may choose to fragment datagrams to 
sizes less than 256 bytes when necessary to increase 
the chances of successful transfer over links with 
a ae however, this should be done as 
a last resort. 


3. The choice between the use of an I or a Ul frame 
for the transmission of a datagram is made by 
examination of the “Class af Service” bits in the IP 
header. Datagrams with the “Reliability” bit set to 
one must be sent via I frames over regular AX.25 
Level Two connections. Datagrams with the “Low 
Delay” bit set to ane must be sent in Unnumbered 
Information (UI) frames. If neither or both bts are 
set, then each link node may make its own choice 
between I and UI frames based om local 
considerations. 

The interpretation of the " tt is a 
subject for future study; in the meantime it should 
be ignored. 


4. Buffer space permitting, each Level Two 

fg ago should be able to accept and process 
frames containing IP datagrams whenever they 
are received, whether or not a regular Level Two 
comection exists with the sending station or any 
other station. 

5. AX.25 Level Two connections may be estattished an 
demand when needed to transmit datagrams with the 
reliability bit set, or they may be continuously 
ringed iam” sonra on by 
the stations concemed. an AX.25 Level Two 
connection is to be taken down, each station should 
make every effort possible to ensure that any 


Outstanding dat sent via I frames (i.e, 
datagrams with “reliability” bit set) have been 
sent and acknowledged before going into te 
disconnected state. 


1 It may be cccasionall a eee 


necess we 
thar came upper te, ful mulple ronhecict 


Seg teienus 


Wi s. 
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6. There is no effort to mwintain Level Two 
connections corresponding to any end-to-end virtual 
Circuits that may exist at higher protocol levels. 


6.2 Address Recolaties Protecel 


Whenever a station needs to determine the AX.25 Level 
Two address (i.¢., the amateur radio callsign) of another 
station in its local area corresponding to a given Internet 
address, it shall use the A Address Resolution 
Protocol (ARP) as described in RFC &26. The value of 
the “hardware type" field in an ARP packet has been 
See 2 Ae Oe ean ‘Amateur Radio 


Esch ARP broadcast and reply packet is sent in a separate 
Ul frame immediately after the AX.25 Level 3 Protocol 
1D a Oe ee 
The contents of the AX.25 Level Two destination field to 
be used for all broadcast packets (including ARP) shall be 
“GST” with SSD 0. 


